Date: Sun, 1 Aug 93 04:30:02 PDT 

From: Packet-Radio Mailing List and Newsgroup <packet-radio@ucsd.edu> 
Errors-To: Packet-Radio-Errors@UCSD.Edu 

Reply-To: Packet-Radio@UCSD.Edu 

Precedence: Bulk 

Subject: Packet-Radio Digest V93 #225 

To: packet-radio 


Packet-Radio Digest Sun, 1 Aug 93 Volume 93 : Issue 225 


Today's Topics: 
Comments wanted for KPC3 
CP/M software? (3 msgs) 
DSP-2232 output level. 
Is rec.radio.amateur.packet about to die? Read on. (3 msgs) 
Packet can't work (2 msgs) 
Which TNC to Buy ? 
X1J and the DR200 


Send Replies or notes for publication to: <Packet-Radio@UCSD.Edu> 
Send subscription requests to: <Packet-Radio-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Packet-Radio Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/packet-radio". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: 30 Jul 93 21:00:43 GMT 

From: ogicse!hp-cv!hp-pcd!hpspkla! pace@network.ucsd.edu 
Subject: Comments wanted for KPC3 

To: packet-radio@ucsd.edu 

Scott R. Ehrlich (sehrlich@lynx.dac.northeastern.edu) wrote: 


: A friend of mine is looking for an easy to use, cheap, TNC. 
: Some friends of mine have the KPC3 and really like it. 


: I'd like to see what others on the net have so say about the unit. 
: Thanks much. 


: I will try to summarize the responses (if I get enough). 


Scott 

| Scott Ehrlich Internet: acm_se@neu.edu 

| Amateur Radio: wy1z AX.25: wy1z@nOary.#nocal.ca.usa.na 
| Scott Ehrlich Internet: acm_se@neu.edu 

| Amateur Radio: wy1z AX.25: wy1z@nOary.#nocal.ca.usa.na 


Date: 30 Jul 93 15:17:22 GMT 

From: psinntp!gdc!horzepa@uunet.uu.net 
Subject: CP/M software? 

To: packet-radio@ucsd.edu 


Anyone aware of any packet radio terminal emulation software for CP/M? 
I had read about some recently (the last 2-3-4 months), but misplaced 
the information. Any leads would be appreciated. 


73% 


Stan, WATLOU 


Stan Horzepa ~ phone: 203-758-1811 x7369 
Technical Writing Supervisor ~ email: horzepa@gdc.com 
General DataComm, Inc. ~ radio: WALLOU 

P. 0. Box 1299 ~ packet radio mail: WATLOU@N4GAA 


a 


Middlebury, CT 06762-1299 TCP/IP packet radio: 44.88.0.14 


meen mmr eee ne mm ee What! - Me Worry? ~~~~~nnw www nnn nnn nnn nnn 


Date: Sat, 31 Jul 1993 00:03:14 GMT 

From: news.cerf.net!crash!newshub.nosc.mil!dog.ee.lbl.gov!overload.lbl.gov!agate! 
spool.mu.edu!sdd.hp.com!col.hp.com!news.dtc.hp.com!srgenprp!alanb@network.ucsd.edu 
Subject: CP/M software? 

To: packet-radio@ucsd.edu 


Stan Horzepa (horzepa@gdc.com) wrote: 


: Anyone aware of any packet radio terminal emulation software for CP/M? 
: I had read about some recently (the last 2-3-4 months), but misplaced 
: the information. Any leads would be appreciated. 


I don't know of any specifically for packet, but there's lots of general- 
purpose terminal programs that should work fine for most TNCs. Contact 
the FOG users group (I can get the address if you don't have it) for 
some freeware CP/M terminal programs. 


AL N1AL 


Date: 31 Jul 1993 02:09:26 GMT 

From: usenet.coe.montana.edu! grapevine.lcs.mit.edu!ai-lab! regnad@decwrl.dec.com 
Subject: CP/M software? 

To: packet-radio@ucsd.edu 


I use the CP/M terminal program ZMP for packet. It works well enough, and 
includes the YAPP protocol (in a seperate overlay). 


Paul Prescott 
N1AAC 
regnad@gnu.ai.mit.edu 


Date: 30 Jul 93 13:05:27 GMT 

From: ogicse!uwm.edu!math.ohio-state.edu!darwin.sura.net!news.Vanderbilt.Edu! 
news@network.ucsd.edu 

Subject: DSP-2232 output level. 

To: packet-radio@ucsd.edu 


I going to be using a DSP-2232 for digital satellite as well as HF 
applications, and am finding that while it has a lot of very impressive 
digital capabilities, that the analog parts are a little rough around the 
edges. Of particular concern is that the values used in the interchip 
coupling components result in the output voltage being roughly 
proportional to the baud rate. So far I am using a small box with lots 
of resistors, one for each radio and mode. Does anyone have a clean fix 
or mod? AEA essentially says that this is "normal" and should cause no 
problem since you just use the mike gain. However, for most modes you need 
to bypass the normal audio feeds. There must be a way to do this right, 
since the competing DSP-12 have constant output for all modes. 


Alan 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKK 


Alan P. Biddle, Ph.D. PACKET WA4SCA @ W4HHY.TN.USA.NA 
Computers of Arisia 

1778 Pleasant Hill Road INTERNET WA4SCAG@AMSAT . ORG 

Franklin, TN 37064 BIDDLEAP@CTRVAX. VANDERBILT . EDU 
(615) 776-2056 

(615) 330-2569 CIS 73260,1450 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK 


Date: 31 Jul 93 18:16:58 GMT 

From: ogicse!emory!rsiatl!ke4zv! gary@network.ucsd.edu 
Subject: Is rec.radio.amateur.packet about to die? Read on. 
To: packet-radio@ucsd.edu 


In article <23bf£s4INNd1h@network.ucsd.edu> brian@nothing.ucsd.edu (Brian Kantor) 
writes: 

> 

>Well, you see, a bunch of newbies decided they had a better way to run 

>things, and managed to dupe enough people into voting for a few of the 
>massive numbers of groups they thought would help balkanize the 

>discussions they didn't want to see any more, so there are a bunch of 

>new groups. 


Don't hold back, tell us how you xreallyx feel Brian. :-) 


The issues were settled by a couple dozen votes out of a couple 
hundred total votes. Most of the thousands of readers of the 
ham-radio groups didn't speak. But that's the way Usenet works. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


| gatech!wa4mei! ke4zv! gary 
| uunet!rsiatl!ke4zv! gary 
| emory!kd4nc!ke4zv! gary 

| 


Date: 31 Jul 93 02:33:23 GMT 

From: pacbell.com!amdahl!amdahl!ikluft@ames.arpa 

Subject: Is rec.radio.amateur.packet about to die? Read on. 
To: packet-radio@ucsd.edu 


brian@nothing.ucsd.edu (Brian Kantor) writes: 
>Well, you see, a bunch of newbies decided they had a better way to run 


>things, and managed to dupe enough people into voting for a few of the 
>massive numbers of groups they thought would help balkanize the 
>discussions they didn't want to see any more, so there are a bunch of 
>new groups. 


Brian, I'm shocked (almost.) For someone with a good understanding of UseNet, 
you are showing very little respect for some of the few established UseNet 
processes (i.e. voting.) OK, so some of it didn't go the way you wanted - 

but it was voted on and the votes passed by the required 2-to-1 margins and 
100 more yes's than no's. 


Now you're saying those people who voted yes were duped into it? That would 
have required someone to be campaigning for it. When the voting started, I 
didn't see anyone doing that, and I was encouraging people to vote by their 
opinion whether it was yes or no. (My reason was that it would be worse to 
campaign and risk a backlash from people who didn't like it.) 


So you might want to consider the possibility that a 2-to-1 majority really 
did choose those newsgroups that passed. And I mean each person on their 
own chose it. 


>[...] Thus the result of the vote was that all that's being 
>accomplished is to change the name of a successful group to one that's 
>a bit less obvious, and which - to this point at least - has not been 
>very well received by the Usenet ham populace. 


Any why might that be?? Hmmm... Perhaps because someone is still gating 

a mailing list into the soon-to-be-rmgroup'ed newsgroup. That's almost 
certainly maintaining some level of traffic here when it should be dwindling 
to nothing during the transition to rec.radio.amateur.digital.misc. As 

long as there's discussion in rec.radio.amateur.packet, many people won't 
move to the new group. 


On the bright side, I saw that you've posted a question about what people 
want with the mail lists. That's good - please expedite some sort of action 
on the matter. It appears like the available options are 
* moving the mail list to rec.radio.amateur.digital.misc (with somewhat of 
a mismatch in scope between the digital and packet topics), 
x detaching the mailing list from the newsgroup entirely, 
shutting down the mailing list, or 
* changing the name of the mail list to match the new newsgroup. (My guess is 
this one is not likely to happen.) 


+ 


It's your choice since you're the mail list gateway administrator. But choose 
something soon. 

Ian Kluft KD6EUI PP-ASEL Amdahl Corporation, Open Systems Development 
ikluft@uts.amdahl.com Santa Clara, CA 


[disclaimer: any opinions expressed are mine only... not those of my employer] 


Date: Fri, 30 Jul 1993 16:56:24 GMT 

From: pravda.sdsc.edu!news.cerf.net!usc!math.ohio-state.edu!sol.ctr.columbia.edu! 
news.unomaha.edu! cwis!pschleck@network.ucsd.edu 

Subject: Is rec.radio.amateur.packet about to die? Read on. 

To: packet-radio@ucsd.edu 


In <23bfs4INNdih@network.ucsd.edu> brian@nothing.ucsd.edu (Brian Kantor) writes: 


>da884@cleveland.Freenet.Edu (David Toste) writes: 

>> 

>>NOTE: rec.radio.amateur. packet 0921 rec.radio.amateur.digital.misc 
>> 

>>Looks to me that the last day for this group is on Sept 21th~!!! 

>> 

>>What gives? 


>Well, you see, a bunch of newbies decided they had a better way to run 
ANNNANANAA 


If being on the net for almost 3 years, and making substantial 
contributions to the FAQ's and other information resources makes one a 
"newbie," then I and everyone else on rra-reorg (now rra-wg) is guilty 
(Hear that Jay? You're a "newbie!" :-). We've also made it clear that 
we recognize your experience, and seek your opinions whenever possible 
(although we may not always agree). 


One of the risks of a heterogeneous, distributed environment like 
Netnews is that others are going arrive on-scene and possibly take the 
newsgroups in directions other than what the originators wanted. Ina 
voluntary environment, you've gotta lead, follow, or get out of the way. 
If a group of motivated people, with the support of a majority of the 
readers, want to move in a specific direction, I see no cause for 
complaint. Don't forget that every new newsgroup passed with a 2/3 
majority of the readership and at least a 100-vote margin between yes 
and no. 


>things, and managed to dupe enough people into voting for a few of the 
>massive numbers of groups they thought would help balkanize the 
>discussions they didn't want to see any more, so there are a bunch of 
>new groups. 


>Some of these new groups are working out well - the antennas and 
>homebrew groups have proven to be popular. Others are nearly idle. 


I think there's a complement in there somewhere. Actually, all of the 
newsgroups are successful. If you are referring to the *.space group, 
that at least serves as a target for the satellite elements, space 
bulletins, and "Space News" that crowded Info-Hams. 


>One of the ideas was that rec.radio.amateur.packet (formerly known as 
>rec.ham-radio.packet) was to be superseded by a two or more new groups, 
>of which rec.radio.amateur.digital.misc was one. However, the votes 
>weren't there for the other ...digital group(s), and they didn't get 
>created. Thus the result of the vote was that all that's being 
>accomplished is to change the name of a successful group to one that's 
>a bit less obvious, and which - to this point at least - has not been 
>very well received by the Usenet ham populace. 


>It would have been wisest, perhaps, to make the replacement of 
>rec.radio.amateur.packet with a new group/name contingent on more than 
>one of the new digital subgroups passing, otherwise to leave things 
>well enough alone. That wasn't what was done. 


There is no way such "conditional" referenda can be performed within 

the present Usenet voting guidelines. We had to consider all of the RFD 
input, and go with a set of groups that had the greatest support, and 
least damage if only some of them passed. 


Such are the pitfalls of a collaborative, democratic process where the 
results are not known in advance. It was undesirable from a number of 
technical perspectives to have a "split" hierarchy under 
rec.radio.amateur.[digital,packet], hence the desire to add a *.misc 
group. I'll admit it was truly a surprise that there would be support 
(or at least lack of objection) to splitting packet into 
digital.misc/digital.tcp-ip in the RFD, only to have a significant number 
of people vote for one and not the other (about 20-30, I believe). 

We guessed somewhat wrong, but I don't see how anyone could have guessed 
any better, based on the available information. 


Of course, since newsgroup votes can be revisited in 6 months, you'd 
better believe that rec.radio.amateur.digital.tcp-ip is going to 
reapproached. Not to supersede TCP-GROUP (as that clearly is a 
desirable semi-private developer's and expert-user's mailing list, 
thanks for pointing that out in the RFD), but to create a user-level 
Usenet newsgroup for a significant subset of packet experimentation, 
independent of any pre-existing mailing lists. 


I xHOPEx I'm not reading your objections to digital.misc as an 
implication that you're not going to gateway PACKET-RADIO to it at the 
appropriate time. That would be a extremely immature, bitter, and 
obstructionist thing to do (which is why I'm pretty certain I'm 
mistaken) . 


We've been pretty successful recently (for the past year at least), in 
agreeing-to-disagree on certain issues, and not turning the ham-radio 
groups into another meta-discussion battlefield over parochical, 
minority-interest issues. I hope that this isn't going to get ugly 
again. 


Come on Brian, let's work together, and not at potentially 
cross-purposes. 


73, Paul W. Schleck, KD3FU 


pschleck@unomaha. edu 


Date: 31 Jul 93 18:25:26 GMT 

From: ogicse!emory!rsiatl!ke4zv! gary@network.ucsd.edu 
Subject: Packet can't work 

To: packet-radio@ucsd.edu 


In article <25257@acorn.co.uk> agodwin@acorn.co.uk (Adrian Godwin) writes: 
>In article <1865@arrl.org> jbloom@arrl.org (Jon Bloom, KE3Z) writes: 
>>> 

>>>to duplex repeaters instead of digipeaters to solve it. The hidden 
>>>terminal problem goes away because now you hear everything the 
>>>repeater hears in real time. And, if you operate your station in 
>>>full duplex as well, you can even implement CD. 

>> 

>>Has anyone actually implemented CD that way? I'd love to get in 
>>touch with anyone who has and who would be willing to write it up 
>>for QEX or the Digital Conference Proceedings. 

> 

>How would you implement it ? If you get a collision, the output of 
>the repeater will be one of : 


Unchanged, due to FM capture effect. 


The losing node should still stop transmitting, as it worsens the noise 
at the repeater - but to do so, it's got to monitor the repeater output 
to determine who won. This is particularly awkward if you've got a high 
speed system that uses DMA, since the processor doesn't know what the 
data is until it's all received. 

It's possible SDLC hardware addresses could be used, though. 


Completely screwed up, since both signals are received. 


VV VVV VV VV VV VV 


This would probably be less common unless the transmitter power settings 


> were carefully managed, but would appear as an active carrier together 
> with an unrecoverable data clock at the repeater's input. That might 

> be hard to distinguish from a too-distant user, but I'm not sure. 

> 

>Either way, it doesn't seem to scale too well to a faster system, where 
>the round trip time is comparable with the packet length. In this case, 
>you only find out about the collision after it happened 


You've identified the core problem, round trip time. Conceptually, 
it's simple to implement CD. You just keep a FIFO of the last few 
bits you transmitted and match them against the bits being received 
from the repeater. If they're the same, keep transmitting, if they're 
different, stop. The problem, as you've noted, is that stations at 
different distances from the repeater have different round trip 
times. This requires a synchronizing adjustment be made. In the 
pathological case, the synchronizing delay is longer than the 

packet. 


Gary 


Gary Coffman KE4ZV 
Destructive Testing Systems 
534 Shannon Way 
Lawrenceville, GA 30244 


You make it, 
we break it. 
Guaranteed! 


| gatech!wa4mei! ke4zv! gary 
| uunet!rsiatl!ke4zv! gary 
| emory!kd4nc!ke4zv! gary 

| 


Date: 30 Jul 93 17:10:43 GMT 

From: pipex!uknet!acorn!agodwin@uunet.uu.net 
Subject: Packet can't work 

To: packet-radio@ucsd.edu 


In article <1865@arrl.org> jbloom@arrl.org (Jon Bloom, KE3Z) writes: 
>> 

>>to duplex repeaters instead of digipeaters to solve it. The hidden 
>>terminal problem goes away because now you hear everything the 
>>repeater hears in real time. And, if you operate your station in 
>>full duplex as well, you can even implement CD. 

> 

>Has anyone actually implemented CD that way? I'd love to get in 
>touch with anyone who has and who would be willing to write it up 
>for QEX or the Digital Conference Proceedings. 


How would you implement it ? If you get a collision, the output of 
the repeater will be one of : 


Unchanged, due to FM capture effect. 


The losing node should still stop transmitting, as it worsens the noise 
at the repeater - but to do so, it's got to monitor the repeater output 
to determine who won. This is particularly awkward if you've got a high 
speed system that uses DMA, since the processor doesn't know what the 
data is until it's all received. 

It's possible SDLC hardware addresses could be used, though. 


Completely screwed up, since both signals are received. 


This would probably be less common unless the transmitter power settings 
were carefully managed, but would appear as an active carrier together 
with an unrecoverable data clock at the repeater's input. That might 

be hard to distinguish from a too-distant user, but I'm not sure. 


Either way, it doesn't seem to scale too well to a faster system, where 
the round trip time is comparable with the packet length. In this case, 
you only find out about the collision after it happened 


-adrian 


Date: 29 Jul 93 14:17:44 EDT 

From: pacbell.com!iggy.GW.Vitalink.COM!wetware!spunky.RedBrick.COM! psinntp! 
psinntp! pbs.org! pbs! jernandez@network.ucsd.edu 

Subject: Which TNC to Buy ? 

To: packet-radio@ucsd.edu 


I am new to the packet game in amateur radio. I understand how it works 
because I am 

because I am in the communication business. What I need to know is which 

TNC people recommend. Which is better: the PK-232 or the MFj-1278. I am 

interested in a unit that will do packet as well as other modes. 


Thanks 
John 
KA2YAP 


Date: Fri, 30 Jul 1993 04:57:28 GMT 

From: usenet.coe.montana.edu!netnews.nwnet.net!raven.alaska.edu!aurora.alaska.edu! 
ifjrs@decwrl.dec.com 

Subject: X1J and the DR200 


To: packet-radio@ucsd.edu 


In article <22s7qt$alj@gopher.cs.uofs.edu>, bill@gopher.cs.uofs.edu (Bill 
Gunshannon) writes: 


> 
> Has anyone with access to the source looked at putting a version 
> of X1? on the DR200?? It seems that the dual port box would 
> make a great IP gateway between a local LAN and a backbone. 
> 
> bill  KB3YV 
> 
> -= 
> 
> Bill Gunshannon | "There are no evil thoughts, Mr. Rearden" Francisco 
> bill@cs.uofs.edu | said softly, "except one; the refusal to think." 
> University of Scranton | 
| 


dtinclude <std.disclaimer.h> 


Vv 


Scranton, Pennsylvania 
Bill, I've been pushing this for almost a year! I sent a packet last Dec. (?) 
to the author, and got an acknowledgement that he received my msg, but that 

he hadn't yet had a chance to read it. Hadn't heard anything since, so I 
sent another one just a few days ago re the possible porting of X1? to the 
DR-200. So far, no response, but let's give it a few days! 


Also, if others like this idea, let's get a little vocal here, as this is 
the first mention I've seen of the DR-200 in ages. 


I don't get on here all that often, so it might be a good idea (even though 
it's not exactly tcp/ip related) to the tcp-group? 


73, John 


John Stannard 


ifjrs@acad3.alaska.edu BITNET: IFJRS@ALASKA 
KL7JL@KL7IL.AK.USA.NA k17jl.ampr.org [44.22.0.1] 
"God is the Answer!" "Oh?? ... er, ... What was the Question?" 


Date: 30 Jul 93 16:58:52 GMT 
From: pipex!uknet!acorn! agodwin@uunet.uu.net 
To: packet-radio@ucsd.edu 


References <1993Jul28.034200.9730@cs.yale.edu>, <25223@acorn.co.uk>, 


<1993IJu129 .180807 .13354@ke4zv.uucp>du 
Subject : Re: Packet can't work 


In article <1993Ju129.180807.13354@ke4zv.uucp> gary@ke4zv.UUCP (Gary Coffman) 
writes: 

> 

>Channel pathology can still be a problem if stations aren't using 
>p-persistance backoff. Stations can still butt heads again and 
>again if they use a fixed Dwait and both happen to start during the 
>window of vulnerability. And they xwillx always start during the 
>window if the channel is busy. Both will try to transmit as soon 

>as data carrier from a previous channel user drops. So p-persistance 
>is essential to making a busy channel work, whether it's duplex or 
>simplex. 

> 


Right, but p-persistence only helps by deliberately introducing some 
dead-time, just as polling systems introduce their own overhead. 


In both cases, the inefficiency introduced is related to the number 
of users on the channel (since the p-persist coefficient is supposed 
to be related to the expected load) but it's possibly more convenient 
to have the central hub adjust the loading than the user's nodes. 

Of course, this doesn't preclude the user's nodes being adjusted by 
some other, centralised authority based at the repeater. 


-adrian 


Date: Thu, 29 Jul 1993 18:37:14 GMT 

From: dog.ee.lbl.gov!overload.1lbl.gov!agate!howland.reston.ans.net! 
vixen.cso.uiuc.edu!newsrelay.iastate.edu!news.iastate.edu! jvp@network.ucsd.edu 
To: packet-radio@ucsd.edu 


References <1993Ju123.230640.10707@emba.uvm.edu>, <fArVSAJABh107h@pauln.uucp>, 
<tom_taylor-280793174257@kip-27.taligent.com> 
Subject : Re: NOARY 


In <tom_taylor-280793174257@kip-27.taligent.com> tom_taylor@taligent.com (Tom 
Taylor) writes: 


>Not only that, but the custom software he wrote runs on his own network of 
>Sun machines. At least it did six months ago when he came and gave a 
>talk at the Apple ham radio club. 


Not only that, but Bob's BBS software is the best I have _ever_ seen. 


| Jim Van Peursem - Dept of EE and CprE - Iowa State University | 
| Ames, IA 50011 - internet: jvp@iastate or tools1.ee.iastate.edu | 


End of Packet-Radio Digest V93 #225 
KA KKKK KKK KK IKK KKK AKIRA KKK 


